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A  High  Level  Real-Time  Programming  Language 


ABSTRACT 

COAL  is  a  high-level  language  for  writing  real-time  programs,  particularly 
aimed  at  robotics  applications.  Our  presentation  includes  an  informal  description 
of  the  langimge,  a  formal  semantics  for  most  of  the  constructs,  and  a  few  exam- 
ples of  typical  use.  The  most  prominent  features  of  COAL  are  variables  whose 
value  changes  continuously  with  time,  and  extensive  use  of  real-valued  functions. 
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A  High  Level  Real-Time  Programming  Language 


1.  Introduction 

We  present  here  an  outline  of  a  robot  programming  language,  COAL  (Continuous  Action 
Language),  together  with  a  formal  semantics.  COAL  is  designed  to  support  an  abstraction  of  pro- 
gramming which  can  operate  in  a  continuous  fashion.  Variables  can  change  values  continuously 
over  time,  execution  can  be  instantaneously  interrupted  in  response  to  an  event,  and  so  on.  Such 
constructs  must  be  implemented  in  terms  of  discrete  steps,  but  COAL  expresses  the  idealization 
behind  the  implementation,  in  the  way  that  real  arithmetic  is  the  idealization  behind  floating  point 
arithmetic.  In  this  paper,  we  will  describe  the  basic  elements  of  COAL,  define  a  formal  semantics, 
and  present  a  few  typical  programming  examples.  We  have  not  yet  addressed  the  question  of 
implementation. 

2.  Overview  of  COAL 

2.1.   Variables: 

COAL  supports  at  least  the  following  types  of  variables:  booleans,  integers,  real  valued  vec- 
tors (elements  of  /?"),  continuous  functions  from  /?""  to  R"  (called  "real  functions"),  and  integer 
semaphores. 

Certain  global  variables  will  be  bound  to  the  input  and  output  devices  of  the  particular 
robotic  system.  Sensor  variables  are  associated  with  particular  sensors.  At  each  moment  in  time, 
the  value  of  the  variable  is  the  current  measurement  of  the  sensor.  Effector  variables  are  associ- 
ated with  parameters  of  the  robot's  effectors.  Changing  the  value  of  the  variable  causes  a  motion 
by  the  robot.  Effector  variables  must  therefore  be  generally  changed  continuously.  The  global 
variable  clock  always  has  the  current  time  as  its  value. 


-2- 

Anonymous  variables  include  individual  cxxsrdinates  and  time  derivatives  of  vector  variables. 
Thus,  if  V  is  a  vector  in  R^,  then  V[l]  is  its  x-component;  V  is  its  time  derivatives  (when  this 
derivative  is  finite);  and  V[l]'  is  the  derivative  of  the  x-component. 

2.2.  Expressions 

An  expression  may  be  a  constant,  a  variable,  or  a  function  applied  to  expressions.  Functions 
may  be  either  built-in  or  user-defined.  The  built-in  functions  include  at  least  the  arithmetic,  tri- 
gonometric, and  exponential  functions  (with  inverses);  constructor  functions  and  simple  geometric 
operators  for  vector  variables;  differentiation  and  integration;  and  lambda  abstraction  and  applica- 
tion. 

2.3.  Primitive  Statements 

There  are  two  kinds  of  primitive  statements:  assignment  statements,  and  synchronization 
primitives.  For  simplicity,  we  will  use  Dijkstra's  "wait"  and  "signal"  ("F*  and  "V")  as  the  synchoni- 
zation  primitives.  COAL  differs  from  standard  languages  in  that  there  are  four  different  tyjjes  of 
assignment:  "assign",  "bind",  "follow",  and  "graph". 

"Assign(V*-£)"  is  the  usual  assignment  statement.  E  is  evaluated  once  and  its  value  is  stored 
in  V.  Thus  "assign(X*-X+l)"  increments  X  by  1. 

"Bind(V-£')"  is  continuous  assignment,  such  as  found  in  SERVOL  (see  [1]).  The  value  of  V 
is  kept  equal  to  the  current  value  of  E.  Thus  if  P  and  T  are  sensor  variables  corresponding  to 
pressure  and  temperature,  then  bind(XW*r)  keeps  X  equal  to  their  product.  Derivatives  of  a  vari- 
able may  he  bound;  if  so,  the  bind  statement  must  specify  the  initial  conditions  on  the  lower-order 
derivatives.  For  example  "bind  (V'-/?r;  V~5)"  fixes  the  derivative  V  to  the  instantaneous  value 
of  DT,  starting  with  V=5.  "bind(V"-- it*V;  V'-6r  V~0)"  causes  V  to  move  in  accordance  with  the 
harmonic  equation,  with  an  initial  displacanent  of  0  and  an  initial  velocity  of  6.  Some  further 
restrictions  on  the  use  of  "bind"  are  explained  below. 

ToUowiV^y  is  used  to  cause  a  variable  to  trace  out,  over  time,  a  precomputed  function. 
The  value  of  E  must  be  a  particular  time  function  /  at  the  time  the  statement  is  invoked.  The 
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effect  of  the  statement  is  to  cause  the  value  of  V  at  subsequent  times  T  to  be  equal  to  f(T).  By 
convention,  all  the  global  variables  in  £  Eire  evaluated  when  the  follow  statement  is  entered.  For 
instance,  let  A'  be  an  effector  variable  representing  the  robot's  x-coordinate.  If  the  statement 
"io\low{X'-\(T)(X+T-cUxk))  is  invoked  at  time  Tq  with  the  robot  at  Xq,  then  the  right  hand  side 
evaluates  to  the  function  \(T)(Xq+T-Tq).  While  the  statement  is  active,  the  value  otX  is  continu- 
ally bound  to  the  current  value  of  this  function  of  time.  Since  X  is  an  effector  variable,  the  effect 
is  to  move  the  robot  forward  at  constant  speed. 

"Graph(V'-£)"  is  used  to  save  the  behavior  of  a  variable  over  time  as  a  real  function  over 
time  with  no  global  variables.  E  is  evaluated  continuously.  The  value  of  V  is  a  function  which 
expresses  the  time  variance  of  E  from  the  time  the  statement  is  invoked  until  the  time  that  it 
ends.  For  instance,  let  A  be  a  sensor  variable  representing  the  x-coordinate  of  the  robot,  and  sup- 
pose the  robot,  for  whatever  reason,  moves  forward  at  unit  speed.  If  the  statement 
"io\\ow(XJ{ISTORY'-X)"  is  invoked  at  time  Tq  when  the  robot  is  at  location  Xq  then  XJIISTORY 
becomes  the  real  function  \{T)(Xq+T-T(^.  The  domain  of  X_HISTORY  as  a  real  function  is  the 
interval  starting  at  Tq  and  ending  either  at  the  current  time,  or  at  the  time  when  the  "follow"  state- 
ment came  to  an  end,  whichever  is  first. 

"Graph"  can  be  used  together  with  "follow"  to  implement  robot  giiiding,  whereby  a  robot 
learns  a  sequence  of  actions  by  being  moved  through  them.  The  program  would  use  a  "graph" 
statement  to  record  the  desired  motion  in  a  variable  V,  and  then  a  "follow"  statement  to  repro- 
duce them.   "Graph"  is  somewhat  analogous  to  the  "history"  statement  in  SERVOL  [1]. 

In  constrast  to  "assign",  where  the  action  can  be  thought  of  as  being  performed  instantane- 
ously, "bind",  "follow",  and  "graph"  require  some  finite  interval  of  time  for  their  f)erformance. 
We  define  them  as  being  active  forever,  except  when  this  is  modified  by  a  "monitor"  statement  in 
the  enveloping  control  structure,  as  will  be  explained  below. 

Circularities  and  multiple  binding  must  be  avoided  in  using  "bind"  and  "graph".  The  state- 
ment "bind(A-X-f-l)"  is  meaningless,  as  is  the  concurrent  execution  of  the  statements  "bind(y'-X), 
bind  (Y^X+iy  or  the  concurrent  execution  of  the  statement  "bmd(Y^X),  bind  (X^Y+l)".  It  is 
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allowable  to  bind  the  derivative  of  a  variable  to  be  a  function  of  a  variable.  For  example 
"hindQC  -X)"  causes  X  to  increase  exponentially  with  time.  However  it  is  not  permitted  to  bind  a 
variable  to  a  function  of  one  of  its  derivatives.  There  are  two  reasons  for  this  restriction.  Fu^tly, 
an  equation  of  the  form  X=f{XX  X'  ■■■)  is  not  guaranteed  to  have  a  solution.  Secondly,  proper 
differential  equations,  where  the  highest  order  derivative  is  express  as  a  function  of  the  lower  ord- 
ers, can  be  solved  by  simple  interative  methods:  evaluate  the  function  to  fmd  the  value  of  the 
highest  order  derivative,  and  use  that  value  to  extrapolate  the  next  values  of  the  lower  order 
derivatives.  These  methods  do  not  converge  when  applied  to  equations  of  an  improper  form. 

We  may  formulate  these  conditions  as  follows.  Gjnsider  a  graph  whose  nodes  are  all  the 
variables  and  their  derivatives.  At  any  given  moment  of  execution,  construct  an  arc  from  variable 
i4  to  5  if  A  is  a  derivative  of  5 ,  or  if  there  is  an  bind  or  graph  statement  currently  executing  of 
the  form  "bind(A-£(5))"  or  "graph(A-£(fl))",  where  E{B)  is  an  expression  involving  B.  Then,  at 
each  instant,  this  graph  must  be  acyclic.  Moreover,  if  we  merge  the  nodes  of  a  variable  with  those 
of  its  derivatives  then  none  of  the  resulting  nodes  has  more  than  one  arc  leading  to  it.  The 
correctness  of  these  conditions  must  be  checked  at  run-time  each  time  a  "bind"  or  "graph"  state- 
ment is  invoked.  We  do  not  have  to  include  "follow"  statement  here,  since  the  right  hand  of  "fol- 
low" is  not  continuously  reevaluated. 

User-defined  functions  which  are  invoked  on  the  right  side  of  a  "bind"  or  "follow"  statement 
must  be  such  that  it  makes  sense  to  think  of  evaluating  them  instantaneously  and  continously.  For 
example,  if  the  function  F  had  a  side-effect  of  incrementing  a  global  variable  X  by  1,  then  the 
statement  "bind(V-f  Q) '  would  have  to  increment  X  infinitely  often,  which  is  not  acceptable.  We 
therefore  define  an  instantaneous  function  as  one  where  the  only  variables  accessed  are  the  argu- 
ments (passed  by  value)  and  local  variables;  and  we  require  that  only  instantaneous  functions  be 
used  on  the  right-hand  side  of  a  "bind"  or  "follow"  statement. 

'Tollow"  statements,  like  "bind"  statements,  may  have  as  their  left  hand  side  either  a  vari- 
able or  its  derivative.   "Assign"  and  "graph"  must  have  a  variable  as  a  left  hand  side. 


2.4.  Control  structures. 

COAL  provides  five  statement  level  control  structures: 

1)  Sequencing,  "sequence  [S^;  S2;  ■■.  S„]"  executes  statements  S^,  S2,  ...  in  order. 

2)  Conditionals,  "if  B  then  5^  else  52"  evaluates  the  boolean  expression  B  and  executes  S^  if  B 
is  true,  otherwise  executes  52- 

3)  Loops,  "repeat  5  until  B"  iterates  executions  of  the  statement  S  until  the  boolean  expression 
B  becomes  true  at  the  end  of  an  iteration. 

4)  Exception  raising,  "monitor  B  do  S^  else  ^2"  executes  S^  while  continuously  evaluating 
boolean  expression  B.li  B  ever  becomes  false,  then  the  execution  of  S^  is  aborted,  and  52  is 
performed  instead.  A  basic  use  of  monitor  statements  is  to  bring  an  end  to  bind,  follow,  and 
graph  statements. 

5)  Concurrency,  "concurrent  [5i;52;  •  •  •  ;5J"  executes  statements  5^  through  S„  concurrently. 

This  above  list  constitutes  a  minimal  set  of  basic  control  primitives.  It  is  not  meant  to 
exclude  variants  that  clarify  code  through  "syntactic  sugar",  such  as  loops  with  termination  test  at 
the  end,  one  branch  conditionals,  case  statements,  etc.  Indeed,  we  will  introduce  some  additional 
such  constructs  in  section  4. 

2.5.  Procedures  and  Functions. 

Procedures  and  functions  consist  of  a  set  of  formal  parameters,  a  set  of  local  variables,  and  a 
body,  which  is  a  single  statement.  Functions  have  one  local  variable  designated  as  the  "return" 
variable  whose  value  on  exit  from  the  body  of  the  function  is  returned  as  the  value  of  the  func- 
tion. Functions  and  procedures  are  strongly  typed. 

2.6.  Pragmas 

Since  there  is  a  considerable  gap  between  the  continuous  idealization  expressed  by  the 
language  and  its  discrete  implementation,  it  will  be  useful  to  define  a  number  of  optional  methods 
of  "giving  advice"  to  the  compilers,  where  standard  defaults  are  not  appropriate.    The  most 
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important  such  pragma  would  be  an  indication  of  how  often  a  continuously  evaluated  expression 
should  be  reevaluated.  Other  pragmas  would  be  the  necessary  accuracy  of  the  real  arithmetic  or 
the  appropriate  representation  for  particular  real  functions. 

3.   Formal  Semantics. 

In  this  section,  we  describe  a  formal  semantics  for  the  primitive  statements  and  control  struc- 
tures of  COAL,  ignoring  the  problems  of  expression  evaluation,  and  procedure  invocation.  We 
specify  the  semantics  of  COAL  constructs  in  terms  of  sets  of  traces.  A  trace  is  one  possible 
behavior  of  the  variable  values,  together  with  an  explanation  for  that  behavior.  Formally,  a  trace 
is  a  quadruple  <IJiJ^/f>.  /  is  a  time  interval  of  non-zero  length  that  is  closed  on  the  left  and 
either  dosed  or  infinite  on  the  right.  We  will  use  T;  and  T^  to  designate  the  lower  and  upper 
bounds  of  /.  H  is  a  history  of  the  variables;  namely,  a  function  from  variables  and  time  in  /  to  the 
value  of  the  variable  at  that  time.  We  write  H(V,T)  to  mean  the  value  of  variable  V  at  time  T. 
For  example,  if  variable  FOO  has  value  5  at  time  r=2.8,  then  //('TOO",2.8)=5.  We  extend  H  to 
expressions  in  the  natural  way;  H{'TOO+4" ,2.S)=9. 

F  and  N  describe  the  sequence  in  which  the  primitive  operations  (the  four  assignment  state- 
ments and  the  synchronization  primitives)  are  executed.  With  each  separate  execution  of  each 
primitive  operation  we  associate  an  individual  integer.  The  value  of  the  integer  is  irrelevant;  all 
that  matters  is  that  different  executions  have  different  integers.  N  is  the  function  which  associates 
a  given  integer  with  a  given  statement  being  executed.  F  is  the  function  which  specifies,  for  each 
instant  of  time,  which  executions  are  taking  place.  For  example,  it  might  be  the  case  that  at  time 
r=2.8,  executions  numbers  218  and  556  are  taking  place;  that  218  is  an  execution  of  the  state- 
ment "wait(QUEUEl)";  and  that  556  is  the  statement  "bind(J'~X-t-l)".  Then  we  would  have 
f  (2.8)={218,  556},  ^(218)  =  "wait(QUEUEl)";  and  N(556)  =  "bind(J'-X-f-l)".  If  these  same  state- 
ments are  executed  again  at  later  times,  these  new  executions  would  have  different  numbers. 
Note  that  N(F(T))  is  always  the  set  of  statements  being  executed  at  time  T.  We  say  that  F  and  N 
together  constitute  the  execution  sequence  for  the  history  H. 
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The  semantics  of  an  COAL  program  is  expressed  in  terms  of  al]  the  traces  possible  in  exe- 
cuting that  program.  We  build  up  the  semantic  definition  of  COAL  inductively,  first  defining  the 
traces  for  the  primitive  operations,  and  then  combining  these  to  create  the  traces  for  the  control 
stnictujes.  There  is  a  difficulty,  however.  We  would  like  to  define  the  semantics  of  an  assignment 
statement,  for  example,  so  that  no  variables  change  their  value  except  the  one  being  assigned. 
However,  if  there  are  concurrent  operations,  this  may  not  be  the  case;  other  variables  may  change 
their  values  as  a  result  of  other  processes.  We  therefore  define  two  kinds  of  traces.  A  performance 
of  the  program  is  a  trace  in  which  everything  that  should  happen  does  happen,  but  other  things 
may  happen  as  well.  This  corresponds  to  running  the  program  with  arbitrary  other  concurrent 
processes  running  as  well.  An  execution  of  a  program  is  a  trace  where  only  those  things  that  must 
hajjpen  do  happen,  corresponding  to  running  the  program  with  no  other  concurrent  processes. 
We  define  the  semantics  by  building  the  structure  of  performances  inductively,  and  then,  at  the 
end,  imposing  the  execution  condition. 

To  specify  the  connection  between  the  sensor  and  effector  variables  and  the  real  world  would 
require  a  larger  semantic  theory  that  includes  real  world  statements.  In  terms  of  the  internal  pro- 
gramming language,  the  values  of  sensor  variables  are  entirely  arbitrary. 

We  will  assume  of  all  variables  that  their  values,  as  functions  of  time,  are  everywhere  con- 
tinuous from  the  left,  and,  in  fact,  infinitely  differentiable  from  the  left.  Moreover,  the  set  of 
points  where  any  variable  or  derivative  has  a  discontinuity  from  the  right  does  not  have  any  dus- 
ter point;  that  is,  there  are  only  finitely  many  such  points  in  any  finite  interval.  It  is,  of  course, 
possible  to  write  COAL  prograins  which  violate  these  conditions;  for  example,  to  write  infinite 
loops  where  each  iteration  takes  half  as  long  as  the  last.  Such  programs  are  considered  seraanti- 
cally  invalid. 

In  our  semantic  definition,  we  assume  a  non-standard  model  of  the  real  numbers,  with  infini- 
tesimals. In  real  time  programming,  it  is  generally  useful  to  assume,  at  least  as  a  first-order 
approximation,  that  all  calculations  can  be  performed  before  anything  has  time  to  happen  in  the 
real  world.  On  the  other  hand,  we  do   not  want  to  assume  that  such  calculations  take  identically 
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zero  time,  because  we  want  to  specify  the  order  of  execution  in  terras  of  increasing  starting  times. 
The  non-standard  model  of  the  reals  provides  an  elegant  solution:  calculations  take  infmitesimal 
time.  We  use  a  fixed  infinitesimal  quantity  5  in  defining  the  semantics  of  both  the  assignment  and 
monitor  statement. 

In  all  that  follows,  V"  is  the  nth  derivative  of  V.  In  particular,  V^  -  V. 

We  now  proceed  with  our  formal  definitions: 

Definition  1: 

A  performance  of  the  statement  5="assign(V-£)"  is  the  set  of  traces  <I=[T„T^],HJ^J^>, 
such  that  there  exist  a  time  T^tl  satisfying  the  following: 

T^-Tj  is  infinitesimal; 

for  au  rt(r„r,+6],  HiyX)=H{EJ,); 

for  aU  Td,  N{F{T))={S}. 
In  other  words,  at  some  point  T^  in  /,  E  is  evaluated,  and  its  value  is  assigned  to  V.  V 
retains  this  value  for  at  least  time  5.  The  whole  assignment  takes  an  infinitesimal  time;  then  the 
program  may  move  on  to  the  next  statement.  Fmally,  the  execution  sequence  F  J^  asserts  that  the 
assignment  statement  is  active  during  the  whole  interval.  The  reason  we  do  not  simply  consider  / 
to  be  the  interval  [7'^,7'a  +  8]  is  to  allow  for  the  possibility  of  concurrent  assignments;  the  actual 
assigning  of  one  statement  may  occur  during  the  unspecified  part  of  the  interval  of  the  other.  We 
require  that  V  retain  its  new  value  for  at  least  time  8  in  order  to  allow  the  definition  of  "monitor" 
to  work  with  it  (see  below).  Note  that  the  values  of  all  other  variables  are  completely  uncon- 
strained, to  allow  for  the  possibility  that  concurrent  processes  are  affecting  them. 

Definition  2: 

A  performance  of  the  statement  5="bind(V"-£„;r->-E„_i;  •  •  •  V^fJ"  is  the  set  of  traces 
<J=[Ti,<=°)MJ^J^>,  such  that  there  exists  a  time  T^d  such  that 


T„—Ti  is  infinitesimal; 

for  aU  (r>rj,  H{V",T)=H{E„,T); 

for  all  {px<n),  HiV^,Tj=HiE„T,), 

for  all  (TU),  N(F(T))  =  {S}. 

Inherantly,  a  bind  statement  is  active  forever;  this  may  be  modified  by  a  c»ntaining  monitor 
statement.  We  specify  that  all  during  this  interval  the  highest  derivative  is  bound  to  the 
corresponding  expression,  and  that  the  lower  derivatives  are  set  to  their  starting  values  infmi- 
tesimally  soon  after  the  beginning  of  the  interval. 

Definition  3: 

A  performance  of  the  statement  S="io]lo'w(V"-E„;V"~'^-E„_.^;  ■  ■  ■  V^E(^"  is  the  set  of 
traces  <I=[Ti,<x>)J{J^J^>,  such  that  there  exists  a  time  T^d  such  that 

T^-Ti  is  infinitesimal; 

H(E„,T,)  evaluates  to  the  real  function  e(T);  and  for  all  {T>TJ,  H{V",T)=e{T); 
for  all  (m<n),  H(V^,T„)=H(E„Ti),  _ 

forall(re/),A/(F(r))={5}. 
Here  we  specify  that  E„  is  evaluated  as  a  real  function  at  the  beginning  of  /,  and  that  V"  fol- 
lows the  course  specified  by  that  value. 

Definition  4: 

A  performance  of  the  statement  5="graph(V~£)"  is  the  set  of  traces  <I-[T,,°c>)^^^>, 
such  that  there  exists  a  time  T^tl  siich  that 

T^—Ti  is  infinitesimal; 

for  all  (T>TJ  H(y,T)  evaluates  to  a  time  function  v(T)  such  that, 

for  all  r£(T;,r].  v{T)=H{E,T)\  and 
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for  all  (Td),  N(F(T))  =  {S). 

Here  we  require  that  V  contiiiuously  evaluate  to  a  function  which  expresses  the  whole  history 
of  E  from  T,  until  now.  We  can  abbreviate  the  main  condition  above,  if  T>T'>T„,  then 
{H{V,T)){r)=H{E,T). 

Finally,  we  have  the  semantics  for  the  two  semaphores: 

Definition  5: 

A  performance  of  the  statement  5="wait(V)"  is  the  set  of  traces  <I=[Ti,Tj^/'^>, 
where  one  of  two  cases  applies: 

1)  (Normal  Case)  There  exists  T^e/  such  that 

T^-Tf,  is  infinitesimal; 
//(V.r,)>0; 

«(v,rj=//(v,rj-i; 

there  is  no  subinterval  of  /  of  finite  length  in  which  H{V ,T)=Q;  and 
for  all  TU,  N{F{T))={S). 

2)  (Eternal  Suspension) 

/  is  infinite; 

there  is  no  subinterval  of  /  of  finite  length  in  which  H{V,T)=0\  and 

for  all  Til,  N{F{T))={S]. 

Thus  the  process  waits  until  V  is  positive,  and  then  decrements  it  by  1  and  proceeds.* 
In  the  meantime,  other  processes  can  be  manipulating  V  with  waits  and  signals;  but  V  should 
never  remain  positive  for  a  finite  (non-infintesimal)  length  of  time  without  our  process  tak- 
ing advantage  of  the  fact.  The  restrictions  against  two  processes  accessing  the  same  sema- 
phore simultaneously  will  be  built  into  our  definition  of  "execution". 


•  There  aie  several  possible  definitions  for  "wait"  and  "signal"  given  in  the  literature.  The  one  used  here, 
from  [4),  was  chosen  to  simplify  this  definition. 
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DeflnldoD  6: 

A  performance  of  the  statement  5= "signal  (V)"  is  the  set  of  traces 
<I=[T„T^]^rF^>,  where 

H(y,T,)=HiV,T,)  +  l;and 
for  an  Td,N(F(T))={S}. 

This  completes  the  semantics  for  the  primitive  operations.  The  semantics  for  the  con- 
trol statements  are  derived  by  combining  the  semantics  for  their  arguments. 

DeflnltioD  7: 

Two  functions  N^  and  ^^2  ^^  said  to  be  joinabU  if  their  domains  are  disjoint.  A^  is  the 
join  of  N^  and  Ni  if  the  domain  of  A^  is  the  union  of  the  domains  of  ^^  and  ^21  ^nd  N  agrees 
with  each  on  its  own  domain. 

Deflnitioa  8: 

Trace  P2=<h=[T2.hT2^]^2J'i^2>  fi^  ^ft^r  trace  P^  =  <I^  =  [T^„T^_^]MiJ='iJ^x>  '^^ 
Nj^  and  A^j  are  joinable;  T^^=T2/,  and,  for  all  variables  V,  H^{y ,T^,^)=H2{V  J^.i)-  Th"s,  the 
end  of  the  first  is  the  same  as  the  beginning  of  the  second. 

Definition  9: 

Given  a  series  of  traces  P<^  =  <Ii-[T^i,T^^_^\M\J^\,N,>, 

P2=<h=[T2,iJ2,u]^2J'2rN2>,  ■  ■  ■  /'„=</„  =  [7-„.„r„.J^„/-„A„>,  such  that  />,,,  fits 
after  P^,  we  define  their  sequence  as  the  trace  P-<I=\Ti,T^]JiyFJ^>  = 
sequence(/'i^2'  •  •  •  -^(t)  such  that 

for  all  {T(.[T,^iJi^J)  for  all  variables  V,  H{V,T)=Hi^{V,T); 
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N  is  the  join  of  A/,  •  •  •  N„; 

^(7'M)=n(n.J Un+i(n+i.i);  and 

for  all  (7-£(r,,,,ri,J),  FiT)=F,(T); 

Thus,  the  sequence  is  formed  by  stringing  together  the  separate  traces. 

Defining  the  semantics  of  the  control  structures  is  now  straightforward.  To  shorten  the 
definitions,  we  will  assume  the  notational  convention  that,  for  any  subscript  q,  the  perfor- 
mance p,=</,=[T,_;,r,,j^,/-,,^,>. 

Definition  10: 

Let  statement  S  =  "sequence  [Si;  S2;  ...  S„]"-    A  performance  of  5  is  a  trace  P  sudi 

that  there  exists  performances  /"i^j-  •  •  ■  "^n  of  -^1^2 ^n  respectively  such  that  P^+i 

fits  after  Pi  andP  =  sequence(Pi,/'2,  ■  •  ■  .P„) 

Definition  11: 

Let  statement  5  =  "if  fl  then  S^  else  Sj".  The  trace  /'=<[r„rj^/'//>  is  a  perfor- 
mance of  5  if  either  H(^B ,T,)=TRUE  and  /»  is  a  performance  of  5^  or  H(JB,T^=FALSE  and  P 
is  a  performance  of  S^. 

Definition  12: 

Let  statement  S  =  "repeat  5i  until  B".  The  trace  P  is  a  performance  of  5  if  either 
there  exists  a  finite  sequence  of  performances  PiJ'2 P„  or  an  infinite  sequence  of  per- 
formances PiJ'2'  '  '  '   s"^  ^^ 

P  =  sequence(/'i,/'2,  ••■)■> 

each  Pj  is  a  performance  of  5^; 

Pi+i  fits  after  F^; 

for  k<n,  H^(B,Tt^)= FALSE; 
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if  the  sequence  is  finite,  then  H„{B ,T„^)=TRUE;  and 

if  the  sequence  is  infinite  then  the  series  ri^,T2„,...  diverges. 

The  final  condition,  that  the  ending  times  diverge  if  the  loop  is  infmite,  prevents  us 
from  performing  infmitely  many  loop  iterations  in  finite  time.  To  do  so  would  create  a 
number  of  problems.  Any  COAL  program  which  forces  infmitely  many  iterations  in  fmite 
time  is  considered  semantically  improper. 

Definition  13: 

Let  statement  S  =  "monitor  B  do  Si  else  ^i".  The  trace  P  is  a  performance  of  5  if  one 
of  the  following  two  conditions  is  true: 

1)  P  isa  performance  of  S^,  and  for  all  TU,  H(B,T)=TRUE; 

2)  there  exists  traces  P^yPi  and  P^  such  that 

Pi  is  a  performance  of  S^  and  f  2  is  a  performace  of  S2', 

forall(r€/J^(F,(r))=^(F,(r)) 
for  all  variables  V,  H^{VJ)=Hi{VJ); 

/'  =  sequence(/'^,/'2); 

for  aU  T<T^„-h,  H^{B,T)  =  TRUE;  and 

for  some  Tt{T„„-h,T„„),  Hi{B,T)= FALSE. 

In  the  first  case,  B  is  always  true,  and  so  S-^  executes  without  interruption.  In  the 
second  case,  B  becomes  false  at  some  time  infinitesimally  dose  to  time  T.  In  this  case,  P  is 
divided  into  two  parts.  The  first  part,  P^,  is  a  partial  execution  oi  P^,  a  performance  of  5,. 
Thus,  Pg  agrees  in  all  respects  with  P-^  up  until  T^.  The  second  part,  P,.  '*  a  performance  of 

52. 

The  use  of  the  same  8  here  as  in  the  assignment  statement  is  to  guarantee  that  if  a 
monitor  is  triggered  by  the  effect  of  an  assignment  statement,  then  the  monitor  will  halt 
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execution  before  the  program  passes  onto  the  next  statement. 

In  the  case  where  one  monitor  is  imbedded  in  another  with  the  same  halting  condition, 
the  definition  above  is  iion-deterrainistic  as  to  whether  the  exception  handler  of  the  inner 
monitor  begins  execution.  It  certainly  does  not  execute  for  more  than  time  5. 

Definition  14: 

Let  S  be  the  statement  "concurrent  [5^;  ^t;  •  •  •  S„]".  P-<IMyF,N>  is  a  perfor- 
mance of  5  if  there  exist  FiJ''2  ■  •  •  F„  such  that  <IJ1/'i^N>  is  a  performance  of  5^  and, 
for  all  re/,  FiT)=F,(T)UF2(T)\J  •  •  ■  Uf'nO'). 

Thus,  the  history  of  a  concurrent  action  must  be  a  history  of  each  of  its  components; 
everything  that  must  happen  in  each  component  separately  must  happen  when  they  are  run 
together.  The  execution  sequence  for  the  concurrent  action  is  the  union  of  the  separate 
actions. 

Sometimes  there  will  be  no  history  at  all  which  is  a  history  of  all  the  components.  This 
happens,  for  example,  when  conflicting  'Tjind"  statements  are  made  concurrent.  There  is  no 
history  which  is  part  of  performances  of  both  "\nnd(X-Y)"  and  "hmd(X^Y+l)".  In  this  case, 
the  statement  is  considered  semantically  invalid.  No  behavior  whatever  is  consistent  with  this 
statement.   A  subtle  problem  with  this  approach  is  discussed  in  section  3.1. 

This  completes  our  definition  of  the  performance  of  a  statement.  We  are  now  ready  to 
define  the  execution  of  a  statement.  Conceptually,  an  execution  is  a  performance  in  which 
every  change  of  every  variable  can  be  explained  in  terms  of  the  execution  sequence,  and  in 
which  the  synchronization  constraints  are  observed. 

Definition  15: 

Let  S  be  a  statement  and  let  F  =  <////■//>  t«  a  performance  of  5.  P  is  an  execution 
of  S  iff  the  following  conditions  are  observed: 
1)      Let  l'  =  [TQ,ri]  be  any  subinterval  of  /,  and  let  V  be  any  variable  or  derivative.  If 

fi(V,T(i)'^H(y,T{)  then  cither  V  is  a  sensor  variable  or  one  of  its  derivatives,  or  there 


-15- 

exists  a  time  TW  and  a  statement  StN(F(T))  nMi^MBI  where  5  is  an  "assign", 
"bind",  "foUow",  "graph",  "wait",  or  "signal"  statement  with  V  or  a  derivative  of  V  on 
the  left  hand  side.  Thus,  we  ensure  that  no  variable  changes  without  a  good  reason 

2)  Let  *i  and  ?2  be  two  integers  representing  executions  of  primitive  operations  in  the 
domain  of  N  such  that  N(e{)  and  N(e^  are  both  statements  of  the  form  "wait(V)",  with 
the  same  semaphore  s.  Let  Ii  =  [Tij,Ti^]=F~^(e{),  and  h=['^2.i''^2j=f~K'il-  Thus 
/j  and  /i  are  the  intervals  when  these  particular  executions  take  place.  Then  T^  „  and 
T2u  differ  by  at  least  8.  Given  the  semantics  of  performances  of  "wait",  this  ensure 
that  no  two  processes  continue  past  the  wait  statement  simultaneously. 

3)  Let  ^1  and  ej  ^  ^o  executions  of  statements  of  the  form  "signal(V)".  Let  I^=F~^{ei) 
and  /2~^~^(^2)  ^  ^e  intervals  of  execution,  as  above.  Then  /j  and  h  are  disjoint. 
Thus,  no  two  processes  can  execute  "signal"  statements  simultaneously. 

3.1.   A  Problem  with  CoDciurency. 

The  above  definition  of  concurrent  actions  has  a  serious,  though  subtle,  bug:  it  forces 
computers  to  predict  the  future.  The  problem  is  that,  if  there  are  two  ways  of  performing 
the  beginning  of  some  concurrent  actions,  and  one  of  these  leads  to  a  dead  end  in  the  form 
of  inconsistent  bindings,  then  the  semantics  simply  throws  out  this  path  and  requires  the 
computer  to  take  the  other  path.  However,  there  is  no  way  for  the  computer  to  know  which 
path,  if  either,  will  get  it  into  these  straits;  hence,  the  semantics  cannot  be  implemented. 

An  example  will  clarify  the  problem.  Consider  the  following  program: 
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sequence 
[  assign  (B~  TRUE); 
concurrent 
[  monitor  (B)  bind  p^  -  1)  else  bind  (Y  -  1); 
sequence  [  wait  (S);  assign  (B  -  FALSE);  signal  (S);  bind  (Z  -  1)  ]; 
sequence  [  wait  (S);  bind  pC  -  2);  signal  (S)] 

] 
] 

Thus,  the  boolean  flag  fl  is  set  true  and  then  three  concurrent  operations  are  set  in 
motion.  The  first  binds  X  to  be  1  while  B  is  true,  and  then  does  something  else.  The  second 
sets  fl  to  be  false  in  a  section  protected  by  the  semaphore  S.  The  third  binds  .Y  to  2  in  a  sec- 
tion protected  by  the  semaphore  5. 

In  running  this  code  on  an  actual  computer,  one  would  expect  one  of  two  behaviors.  If 
the  "wait"  from  the  second  concurrent  action  is  executed  first,  then  B  will  be  set  to  FALSE, 
the  binding  of  X  to  1  wiU  cease,  the  signal  will  be  executed,  the  third  concurrent  action  will 
be  allowed  to  proceed,  and  X  will  be  bound  to  2.  K,  however,  the  third  action  is  given  prior- 
ity, then  the  program  immediately  enters  into  an  inconsistent  state  where  X  is  bound  to  both 
1  and  2.  But  in  the  semantics  which  I  have  given,  this  last  is  not  a  behavior  of  any  kind.  The 
only  valid  behavior  is  the  first.  Thus  the  pjrogram  must  follow  the  first  sequence,  which  is 
not  a  reasonable  expectation. 

Intuitively,  one  would  like  to  say  that,  if  there  is  more  than  one  performance  for  the 
initial  part  of  a  program,  then  all  of  these  are  legitimate,  and  if  it  gets  into  trouble  later,  it 
enters  a  "bombout"  state.  The  difficulty  is  in  defining  an  initial  part  of  a  performance  which, 
as  a  whole,  does  not  exist.  A  similar  problem  with  regard  to  physical  actions  was  solved  in 
[2]  by  considering  motions  which  were  physically  impossible  and  to  speak  of  actually  carrying 
out  as  much  of  them  as  are  physically  possible.  The  analogous  solution  here  would  be  to 
define  trace  which  are  iiKonsistent  and  to  say  that,  if  an  intial  part  of  such  a  trace  is  con- 
sistent, then  it  represents  a  performance  of  part  of  the  program.    One  possible  approach 
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raight  be  to  define  "illegal"  traces  which  give  multiple  values  to  variables.  We  have  not 
develop)ed  this  approach  in  detail. 

4.   Examples 

A  few  examples  will  help  to  illustrate  the  use  of  these  COAL  constructs.  To  begin,  we 
will  define  some  additional  control  structures  which  are,  strictly  speaking,  redundant  but  use- 
ful in  practice. 

(1)  A  useful  minor  variant  is  the  one-branch  monitor  "monitor  B  do  S".  This  may  be 
defined  as  "monitor  5  do  5  else  no-op"  where  no-op  can  be  defined  as  an  assignment  to  a 
dummy  variable. 

(2)  The  construct  "delay  until  B",  for  a  boolean  expression  B,  does  just  what  it  sug- 
gests; it  monitors  B  until  it  becomes  true,  and  then  continues.  Using  a  dummy  variable 
DUMMY  we  may  define  wait  as  "monitor  (not  B)  do  bind(Df/A/A/y-l)" 

A  similar  constnict  is  "delay  for  T",  which  causes  the  program  to  suspend  itself  for 
time  T.  This  may  be  defined  as 

"sequence  [  assign  (starttime  -  dock); 

monitor  (dock  <  starttime  -I-  T)  do  bind  (DUMMY^l)  ]" 

(3)  It  is  often  useful  to  have  a  variable  which  keeps  track  of  the  time  elapsed  since  a 
given  starting  time.  We  express  this  using  the  statement  "stopwatch  (W,  U)",  use  W  as  a 
stopwatch  variable,  using  U  as  a  unit  of  time.  We  can  define  this  in  terms  of  our  primitives 
as  "hmd(W'-U;W'^)"  (though  in  a  real  system,  this  construct  would  almost  certainly  have 
some  particular  efficient  implementation). 

(3)  A  timed  loop  "every  T  do  5  until  B"  iterates  executions  of  S  every  T  units  of  time 
until  B  becomes  true.  For  example,  the  statonent  "every  (0.1  second)  do  fire  until  dead" 
causes  the  firing  of  10  shots  a  second  until  it  is  detected  that  the  target  is  dead.  We  may 
define  this  loop  using  the  "repeat"  loop  as  follows: 
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"repcat  seqxience  [  assign  (W  -  dock);  S;  delay  until  (clock  >  W  -H  T)  ] 
until  fl" 
(5)  In  world  modelling,  it  is  often  useful  to  say  that  one  object  moves  with  another. 
One  way  to  state  this  is  that  their  local  frames  of  reference  transform  in  the  same  way.  AL 
[5]  provides  the  "AFFDC  primitive  to  effect  this.  This  can  be  defined  in  COAL  as  follows: 

sequence  [  assign  (reLpos  -  fmd.transf orm(framel ,  frame!)); 
bind  (frame2,  transform(rel_pos,  framel)) 

] 

'Trarael"  and  "frarae2"  are  the  two  object  frames.  'Transform"  applies  a  transform  to 

a  frame  of  reference.  "Find_transform"  finds  the  transform  between  two  given  frames  of 
reference. 
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For  our  first  full  example,*  consider  raising  a  robot  arm  to  touch  the  ceiling.  Assume 
that  the  robot  has  feedback  giving  the  current  altitude  of  the  arm  and  that  he  has  direct  con- 
trol over  the  speed  of  the  motor  raising  the  arm.  Also,  assume  that  the  speed  of  the  motor 
must  be  changed  continuously.  In  order  to  avoid  bumping  the  arm,  we  would  like  it  to  slow 
down  as  it  approaches  the  ceiling.  We  therefore  establish  an  intermediate  height  "control". 
Up  to  "control",  the  arm  will  move  at  maximum  speed.  Past  this  height,  it  will  gradually 
slow  down  until  it  approaches  the  ceiling  at  zero  speed.  We  can  program  this  as  follows: 

Example  1: 

var  altitude  :  real  sensor;  /*  Global  variables  */ 

motorspeed  :  real  effector; 

procedure  raise-arm  (ceiling,  control,  maxspeed  :  real); 
const  maxspeed  =  100;  /*  Units  are  fixed  by  the  system  */ 
var  decelerate  :  real; 
sequence 
[  monitor  (altitude  <  control)  do  bind  (motorspeed  ~  maxspeed) ; 
assign  (decelerate  -  maxspeed  *  2  /  (2  x  (ceiling  -  control)); 
monitor  (motorspeed  >  0)  bind  (d/dt(motorspeed)  -  decelerate) 

1 
If  the  altitude  is  a  directly  controlable  effector  variable,  we  can  achieve  the  same  effect 

by  substituting  "d/dt(altitude)"  for  "motorspeed"  throughout  the  above  code. 


This  is  modified  from  an  example  in  [1]. 
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As  another  example,  we  will  write  a  program  to  move  a  robot  along  a  given  path.  The 
path  is  expressed  as  a  parametrized  function  of  arclength  in  two  dimensions.  We  will 
assume  that  the  robot  should  move  at  constant  speed;  that  he  should  always  point  forward 
along  the  path;  and  that  his  orientation  and  position  are  directly  controlable  effector  vari- 
ables. 

Example  2 

var  position  :  effector  real  [2]; 
orientation  :  effector  real; 

procedure  followpath  (path  :  realfun  (real  -  real  x  real)); 
const  robotspeed  =  100; 
var  arclength  :  real; 
concurrent 

[  stopwatch  (arclength,  robotspeed); 

bind  (position  -  apply  (path,  arclength)); 

bind  (orientation  •-  atan2  (d/dt(position  [2]),  d/dt(position  [1])) 

] 

"Apply"  in  the  code  above  is  functional  application:  "apply(f,x)"  is  f(x). 
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If,  instead,  the  speed  and  angular  velocity  were  the  directly  controlable  parameters, 
then  we  could  modify  the  above  code  as  follows: 

Example  3 

var  speed  :  effector  real; 
angspecd  :  effector  real; 

procedure  followpath2  (path  :  realfun  (real  -  real  x  real)); 
const  desiredspeed  =100; 
var  arclength  :  real; 
concurrent 

[  stopwatch  (arclength,  desiredspeed); 

bind  (speed  -  desiredspeed); 

bind  (angspeed  -  curvature  (path,  arclength)) 

1 

/"  Curvature  (p,  s)  is  a  instantaneous  function  which  computes 

the  curvature  of  a  curve  p  parametrized  by  arclength  at  a  point  s.  */ 
function  curvature  (p  :  realfun  (real  -  real  [2]);  s  :  real)  instantaneous; 
var  curve  :  retiuTi  real;  /*  return  variable  */ 

dp  :  real  [2];  /*  tangent  to  p  at  s  •/ 

d2p  :  real  [2];  /*  normal  to  p  at  s  '/ 
sequence 

[  assign(dp   -  derivative  (p,  s,  1);  /*  1st  derivative  of  p  at  s  */ 

assign(d2p  -  derivative  (p,  s,  2);  /*  2nd  derivative  of  p  at  s  */ 

assign(curve  -  dp[l]  x  d2p[2]  -  dp[2]  x  d2p[l]) 
] 
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If  we  wished  to  add  to  the  first  version  of  "foUowpath"  the  restriction  that  the  robot 
could  only  move  when  the  boolean  flag  "go"  was  set,  we  could  rewrite  it  as  follows: 

Elxample  4 

var  position  :  effector  real  x  real; 
orientation  :  effector  real; 
go  :  sensor  boolean; 

fjrocedure  followpath3  (path  :  realfun  (real  -  real  x  real)); 
const  robotspeed  =  100; 
var  arclength  :  real; 
sequence 
[  assign  (arclength  -  0.0); 
repeat 
monitor  (go) 
do  concurrent 

[  bind  (d/dt(ardength)  -  robotspeed); 
bind  (position  -  apply  (path,  arclength)); 
bind  (orientation  -  atan2  (d/dt(position  [2]),  d/dt(position  [1]))) 

] 

else  delay  until  go; 

] 
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If  the  robot  were  following  another  robot,  whose  position  and  orientation  it  could 
sense,  we  could  use  the  "graph"  and  "follow"  functions  as  follows: 

Example  5 

var  pos2  :  sensor  real  [2];  /*  position  of  the  other  robot  '/ 
orient2  :  sensor  real; 
position  :  effector  real  [2]; 
orientation  :  effector  real; 

procedure  followrobot; 

const  dtime  =  60;  /•  delay  time  between  our  robot  and  the  other  */ 

var  posfun2  :  realfun  (real  -  real  [2]); 

angfun2  :  realfun  (real  -  real); 
concurrent 
[  graph  (posfun2,  pos2); 
graph  (angfun2,  orient2); 
sequence 

[  delay  for  dtime; 
concurrent 
[  follow  (position,  lambda  (T)  (apply  (posfun2,  (T  -  dtime)))); 
follow  (orientation,  lambda  (T)  (apply  (angfun2,  (T  -  dtime)))); 

] 
] 
1 

5.    Related  work 

Previous  general  purpose  real-time  programming  languages,  such  as  PEARL  [6], 
MODULA  [10],  or  GAELIC  [3]  have  provided  such  fadtilies  as  programming  and  synchron- 
izing parallel  tasks,  timing  initiation  of  processes  to  a  real-world  dock,  halting  processes  on 
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intemipts,  and  non-standard  I/O.  Robot  programming  languages  tend  to  provide  these  same 
ctmtrol  structiires,  together  with  more  or  less  general  geometric  primitives  for  describing 
positions  and  motions  of  robot  effectors  or  external  objects.  (See  [5]  for  an  overview.)  For 
example,  AL  [7]  provides  these  capacities  in  the  context  of  a  PASCAL-like  language.  AL 
also  provides  an  AFFIX  function,  which  has  some  of  the  capacities  of  COAL's  "bind".  MINI 
[8]  extends  LISP  with  a  few  basic  robot  functions.  These  can  be  combined  with  ordinary 
LISP  code  to  provide  a  wide  range  of  robot  programmability.  PAL  [9]  allows  the  user  to 
specify  successive  positions  of  the  end-effector  in  terms  of  transformational  equations,  and 
itself  plans  the  motion  between  these  positions. 

More  similar  to  COAL  is  SERVOL  [1].  SERVOL  provides  both  continuous  and 
sequential  assignment,  equivalent  to  COAL's  "bind"  and  "assign";  the  capacity  of  keeping  the 
recent  past  history  of  a  variable,  which  gives  some  of  the  capacities  of  COAL's  "graph". 
Exception  raising  can  be  simulated  to  a  degree  using  conditional  expressions  and  continuous 
assignment.  SERVOL  is  designed  to  r\m  the  inner  levels  on  a  microcomputer  communicating 
with  a  mainframe  host.  The  syntax  and  semantics  of  the  language  are  therefore  simple  and 
not  very  general. 

The  primary  innovations  of  COAL  are  its  use  of  continuous-valued  variables  in  a  uni- 
form way,  and  its  use  of  functions  of  real  arguments  as  basic  data  types.  The  ease  with 
which  a  formal  semantics  may  be  defined  for  COAL  is  indicative  of  the  cleanness  of  the 
underlying  theory. 
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